Object oriented programming is well-known to those skilled in the art of data processing. Object oriented programming provides greater manageability, ease of use, simplicity and product integration in complex application environments such as distributed data processing systems. Object orientation provides software modeling techniques which use individual "object" components that can be constructed into complex systems. One way of logically arranging objects is as a hierarchy of parent objects and child objects where one or more child objects are dependent on each parent object.
Some application programs, particularly those running cooperatively in a distributed system, typically process both locally available objects and objects that must be retrieved from an external unit, such as a remote computer system.
A graphical interface may allow a user to interact with the system to have the system perform user selected operations on an object. For example, a user can select an object by placing a mouse cursor over a displayed object and clicking on a mouse button.
A user can interactively open or expand a displayed object to display objects dependent on the displayed object by issuing such a command after selecting the displayed object. Whenever an open/expand command for a selected object is issued by a user from a computer terminal, the dependent objects (if any) defined as dependent on the selected object are displayed for the user.
All of the objects dependent on the selected object that are already locally present are displayed to the user for further operations. However, the whole application processing typically becomes locked until all the objects requested by the user or other application are retrieved from the external unit(s) thus preventing further operations from being performed on these objects. For example, in a typical window oriented application, the whole process controlling the window is put in a locked status.
The user can be kept informed about the progress of the process for retrieving the dependent objects from the external unit through message windows or status line information displayed for the user. However; the whole application is locked until the retrieve operation for the dependent objects from the external unit is completed.
Having to wait for the external dependent objects is one of many problems with the prior art for accessing dependent objects.
Another problem with the prior art in this area is that the condition is imposed that an object must have at least one dependent object locally defined in association thereto before an application accepts open/expand commands for that object. So, when none of the dependent objects have already been retrieved from the external unit, the selected object cannot be opened or expanded.
It is very hard for the user to know which objects will have dependent objects that are locally available or which of them have to be retrieved from the external unit.
It is an object of the present invention to overcome one or more of the afore-mentioned problems or drawbacks of the prior art.